home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 11484 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.6 KB

  1. Path: nnrp.info.ucla.edu!jmartin
  2. From: jmartin@cs.ucla.edu (Jay Martin)
  3. Newsgroups: comp.lang.c++,comp.lang.eiffel,comp.lang.c,comp.object,comp.software-eng
  4. Subject: Re: Beware of "C" Hackers -- A rebuttal to Bertrand Meyer
  5. Date: 14 Mar 1996 20:02:29 GMT
  6. Organization: University of California, Los Angeles
  7. Message-ID: <4i9u0l$vru@saba.info.ucla.edu>
  8. References: <1995Jul3.034108.4193@rcmcon.com> <314628F2.31C8@aud.alcatel.com> <RMARTIN.96Mar13110714@rcm.oma.com> <4i862r$1evq@saba.info.ucla.edu> <4i99if$8ve@solutions.solon.com>
  9. NNTP-Posting-Host: may.cs.ucla.edu
  10. X-Newsreader: NN version 6.5.0.b3.0 #9 (NOV)
  11.  
  12. seebs@solutions.solon.com (Peter Seebach) writes:
  13.  
  14. >In article <4i862r$1evq@saba.info.ucla.edu>,
  15. >Jay Martin <jmartin@cs.ucla.edu> wrote:
  16. >>No "hacking" is broader than that, it is writing poor code period.
  17.  
  18. >Bullshit.  Read the jargon file.
  19.  
  20. Your jargon file is bullshit (obsolete).  Comes from primitive times
  21. when coding wizardry was cool.  Anything with "hack" in it is now at
  22. best ambiguous (can mean cracking,etc) and mostly negative.  The
  23. meaning of hacking and hackers in this discussion is "anti-software
  24. engineering/ good programming practices".  I wouldn't put "hack" on
  25. resumes.
  26.  
  27. >And for good reason.  The key point is that, if the C programmer were the
  28. >one talking about design concepts, and the Eiffel programmer were talking
  29. >about cool optimizations she learned for the implementation she used, you'd
  30. >hire the C programmer.
  31.  
  32. Yup, but its probably really hard to find "hacker" Eiffel programmers.
  33.  
  34. >>To demonstrate the "C hacker culture" (filed under macho attitudes)
  35. >>here's a random recent example:
  36.  
  37. >>rmartin@oma.com (Robert C. Martin) writes:
  38. >>>No, I disagree with your point.  It is not the responsibility of the
  39. >>>language to make the engineer better.  It is the responsibility of the
  40. >>>engineer to become adept at the language.
  41.  
  42. >>Clear demonstration of views that have left software engineering
  43. >>and entered the "C Hacker Zone".
  44.  
  45. >No, it's a philosophical distinction.
  46.  
  47. Don't see the difference between "C Hacker culture" and "C Hacker philosophy".
  48.  
  49. >I agree with him; it is *impossible*
  50. >to make someone think in high level terms.  A bad programmer will make
  51. >design and stylistic errors in Ada, too.  Languages can prevent typos, and
  52. >low-level errors.  They cannot prevent stupid design.  (Unless Ada can
  53. >detect bubblesort, and optimize it into something better?)
  54.  
  55. No they can't, but good tools should give all the help they can.
  56. Its this black/white macho "I don't need no stinking checking",
  57. "nothing is completely safe, so forget safety" is a hallmark
  58. of the "C Hacker culture".
  59.  
  60.